Closed Bug 1305312 Opened 9 years ago Closed 9 years ago

Assertion failure: [GFX1]: RGBX corner pixel at (0,149) in 300x150 surface is not opaque: 0,0,0,255

Categories

(Core :: Graphics: Canvas2D, defect, P1)

Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: tsmith, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase, Whiteboard: [gfx-noted])

Attachments

(3 files)

Attached file log.txt
Found with debug build. This only seems to happen when running under Xvfb. Crash Annotation GraphicsCriticalError: |[0][GFX1]: RGBX corner pixel at (0,149) in 300x150 surface is not opaque: 0,0,0,255 (t=13.0389) [GFX1]: RGBX corner pixel at (0,149) in 300x150 surface is not opaque: 0,0,0,255 Assertion failure: [GFX1]: RGBX corner pixel at (0,149) in 300x150 surface is not opaque: 0,0,0,255, at /home/worker/workspace/build/src/gfx/2d/Logging.h:513 ASAN:DEADLYSIGNAL ================================================================= ==19214==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb41dcf10ea bp 0x7fb3fb1f9550 sp 0x7fb3fb1f9540 T27) #0 0x7fb41dcf10e9 in mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::WriteLog(std::string const&) /home/worker/workspace/build/src/gfx/2d/Logging.h:514:9 #1 0x7fb41dcf0fc3 in mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::Flush() /home/worker/workspace/build/src/gfx/2d/Logging.h:278:7 #2 0x7fb41dcf0bcd in mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::~Log() /home/worker/workspace/build/src/gfx/2d/Logging.h:270:5 #3 0x7fb41dceffe7 in mozilla::gfx::VerifyRGBXCorners(unsigned char*, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, int, mozilla::gfx::SurfaceFormat) /home/worker/workspace/build/src/gfx/2d/DrawTargetSkia.cpp:199:9 #4 0x7fb41dcdfcef in mozilla::gfx::GetBitmapForSurface(mozilla::gfx::SourceSurface*) /home/worker/workspace/build/src/gfx/2d/DrawTargetSkia.cpp:240:3 #5 0x7fb41dce4c62 in mozilla::gfx::SetPaintPattern(SkPaint&, mozilla::gfx::Pattern const&, float, mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits, float>) /home/worker/workspace/build/src/gfx/2d/DrawTargetSkia.cpp:390:25 #6 0x7fb41dce14f6 in mozilla::gfx::DrawTargetSkia::FillRect(mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, mozilla::gfx::Pattern const&, mozilla::gfx::DrawOptions const&) /home/worker/workspace/build/src/gfx/2d/DrawTargetSkia.cpp:666:18 #7 0x7fb41e058154 in mozilla::layers::FillRectWithMask(mozilla::gfx::DrawTarget*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, float> const&, mozilla::gfx::SourceSurface*, mozilla::gfx::SamplingFilter, mozilla::gfx::DrawOptions const&, mozilla::gfx::ExtendMode, mozilla::gfx::SourceSurface*, mozilla::gfx::Matrix const*, mozilla::gfx::Matrix const*) /home/worker/workspace/build/src/gfx/layers/basic/BasicLayersImpl.cpp:146:3 ... see log.txt for full log.
Flags: in-testsuite?
Attached file test_case.html
Has STR: --- → yes
Priority: -- → P1
Whiteboard: [gfx-noted]
The problem stems from the fact that our implementation of putImageData uses DrawTarget::CopySurface to implement the final blit. We supply it with an RGBA source, but are copying to an RGBX surface. When Skia does this copy, unlike Cairo, it does more or less an actual memcpy, since it has no notion of an RGBX destination. From the spec wiki (https://wiki.whatwg.org/wiki/CanvasOpaque): "The behaviour of putImageData() and putImageDataHD() is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store." So the spec suggests an easy-ish fix: we still need to write out the premultiplied data, but we need to make sure the alpha is opaque. The fastest place to do this is when we are building the premultiplied version of the data, by just ORing a mask onto the alpha depending on whether we want opaque or not. Unfortunately, Skia doesn't have a one-step way to do this that doesn't involve a lot of silly massaging with slow color filters (unlike Cairo), so the DrawTargetSkia::CopySurface implementation remains unchanged.
Attachment #8795153 - Flags: review?(jmuizelaar)
Attachment #8795153 - Flags: review?(jmuizelaar) → review+
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/403d09199a2a write putImageData pixels as opaque for opaque canvas. r=jrmuizel
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: